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Abstract 


This document registers the Enumservice named "vmsg", which is used 
to facilitate the real-time routing of voice, video, and unified 
communications to a messaging system. This vmsg Enumservice 
registers three Enumservice types: "voicemsg", "videomsg", and 
"unifmsg". Each type also registers the subtypes "sip", "sips", 
"http", and "https", as well as the subtype "tel" for the "voicemsg" 
type. 
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Introduction 


ENUM (E.164 Number Mapping, RFC 3761 [1]) is a technology that 
transforms E.164 numbers (the International Public Telecommunication 
Numbering Plan, ITU-T Recommendation E.164 [2]) into domain names and 
then uses DNS (Domain Name System, RFC 1034 [3]) delegation through 
NS records and Naming Authority Pointer (NAPTR) records (Dynamic 
Delegation Discovery System (DDDS) Part Three: The Domain Name System 
(DNS) Database, RFC 3403 [4]) to look up what services are available 
for a specific domain name. 


This document registers Enumservices according to the guidelines 
given in RFC 3761 [1] to be used for provisioning in the services 
field of a NAPTR [4] resource record to indicate the types of 
functionality associated with an end point and/or telephone number. 
The registration is defined within the DDDS (Dynamic Delegation 
Discovery System [4] [5][6][7][8]) hierarchy, for use with the "E2U" 
DDDS Application defined in RFC 3761. 


Voice messaging systems are used widely with telephony and voice 
communication services. The need for a voice messaging service type 
has become clear in order to provide certain applications with direct 
access to various voice messaging services (for example, voicemail), 
most typically via the use of SIP. 


The authors considered the use of Voice Profile for Internet Mail 
(VPIM) [14] but found that VPIM was best suited to the non-real-time 
and non-session-based routing of a voice message once it had been 
deposited into a voice messaging system. Thus, VPIM was a good 
solution for the non-real-time and non-session-based routing of voice 
messages between and within domains, but it did not enable real-time 
interaction with a voice messaging system. 


Thus, a need has been identified for this voice messaging service 
type that would enable, for example, some of the use cases listed in 
this section. 


Video messaging systems, sometimes called visual voice messaging 
systems, are beginning to be used with real-time communication 
services. The need for a video messaging service type has become 
clear in order to provide certain applications with direct access to 
various video messaging services, most typically via the use of SIP. 
Thus, a need has been identified for this video messaging service 
type that would enable, for example, some of the use cases listed in 
this section. 
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Finally, several service providers and software developers have 
indicated that their system for voice messaging and video messaging 
either have been or soon will be unified into a single system. As 
such, they desired to have the option of using an Enumservice type 
that represents a subscriber’s mailbox as being a so-called unified 
messaging repository. Thus, a need has been identified for this 
unified voice and video messaging service type that would enable, for 
example, some of the use cases listed in this section. 


1.1. Selected Use Cases for Illustrative Purposes 


The following is a partial, non-exclusive list of use cases that the 
vmsg Enumservice could address: 


* A called party is busy or does not answer a call. A client or 
server then determines that a messaging service should be used and 
sends the calling party’s session to such a service. The client or 
server needs to be able to determine which server to direct this 
real-time session to, whether that is within or outside of the 
called party’s domain. 


* Similar to the above use case, a real-time session is attempted to 
a messaging system, but that system is currently unavailable. 
Since multiple service type records may be returned by the original 
ENUM query, the client or server could then attempt to initiate a 
session with one or more backup messaging servers in a manner that 
is transparent to the calling party and that supports better 
overall availability of a messaging service. 


* Similar to the above use case, this service type could be used to 
balance load across multiple messaging servers, whether those are 
in the same or in different physical locations. 


* A user with an account on a messaging service needs to connect to 
the messaging service in order to retrieve messages. They initiate 
a real-time session, and an ENUM query is performed to discover the 
messaging server that holds its mailbox. 


* In the process of invoking and supporting a real-time, automated 
and interactive session with a user, whether for message deposit or 
retrieval, VoiceXML files are referenced and utilized, via either 
HTTP or HTTPS. Multiple VoiceXML servers could be associated with 
a user and returned via ENUM query, for the purposes of load 
balancing, for example. 
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Consideration of Other Existing Enumservices 


The authors considered whether this service type could simply use the 
SIP Enumservice type [19], but found that it does not satisfy their 
voice messaging requirements, particularly given the non-SIP URI sub- 
types specified herein. Even with sub-types for SIP URIs, however, 
there are challenges to using the SIP Enumservice type. For example, 
a request for access to such a service could be extended to the 
requesting SIP client, or User Agent Client (UAC), rather than 
relying upon the local policy of a SIP server, or User Agent Server 
(UAS), which means that special routing logic within a UAS cannot be 
relied upon to solve this problem. More importantly, however, the 
authors have found that without this service type, a UAC or UAS will 
be presented with multiple SIP URIs, with no ability other than in 
non-standards-based routing rules or application logic to recognize 
which one is related to a voice messaging, video messaging, or 
unified voice and video messaging service. 


Distribution of Data 


The authors believe that it is more likely that these records will be 
distributed on a purely private basis, but they may also be 
distributed in public ENUM trees. Distribution of this NAPTR data 
could be either (a) on a private basis within a service provider’s 
internal network, (b) on a private basis between one or more parties 
using a variety of security mechanisms to prohibit general public 
access, or (c) openly available. 


Security Considerations 


DNS, as used by ENUM, is a global, distributed database. Should 
implementers of this specification use el64.arpa or any other 
publicly available domain as the tree for maintaining voicemsg 
Enumservice data, this information would be visible to anyone 
anonymously. While this is not qualitatively different from 
publication in a Telephone Directory, it does open or ease access to 
such data without any indication that such data has been accessed or 
by whom it has been accessed. 


Such data harvesting by third parties is often used to generate lists 
of targets for unsolicited information. Thus, a third party could 
use this to generate a list that it can use to make unsolicited 
telemarketing phone calls, or so-called SPAM over Internet Telephony 
(SPIT). Many countries have do-not-call registries or other legal or 
regulatory mechanisms in place to deal with such abuses. 
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As noted earlier, carriers, service providers, and other users may 
simply choose not to publish such information in the public el164.arpa 
tree, but may instead simply publish this in their internal ENUM 
routing database that is only able to be queried by trusted elements 
of their network and/or partner networks, such as softswitches and 
SIP proxy servers. They may also choose to publish such information 
in a carrier-only branch of the el64.arpa tree, should one be 
created. 


Although an E.164 telephone number does not appear to reveal as much 
identity information about a user as a name in the format 
sip:username@hostname or email:username@hostname, the information is 
still publicly available; thus, there is still the risk of unwanted 
communication. 


An analysis of threats specific to the dependence of ENUM on the DNS 
and the applicability of DNSSEC [16] to this is provided in RFC 3761 
[1]. A thorough analysis of threats to the DNS itself is covered in 
RFC 3833 [17]. 


ENUM Service Registration for voicemsg 


.1. Registration for "voicemsg" with Subtype "sip" 


Enumservice Name: "voicemsg" 

Enumservice Type: "voicemsg" 

Enumservice Subtypes: "sip" 

URI Schemes: ”sip:” 

Functional Specification: 

This Enumservice indicates that the remote resource identified can be 
addressed by the associated URI scheme in order to initiate a voice 
communication session to a voice messaging system. 

Security Considerations: See Section 3. 

Intended Usage: COMMON 


Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 
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Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 


4.2. Registration for "voicemsg" with Subtype "sips" 
Enumservice Name: "voicemsg" 
Enumservice Type: "voicemsg" 
Enumservice Subtypes: "sips" 
URI Schemes: ”sips:” 
Functional Specification: 
This Enumservice indicates that the remote resource identified can be 
addressed by the associated URI scheme in order to initiate a voice 
communication session to a voice messaging system. 
Security Considerations: See Section 3. 
Intended Usage: COMMON 


Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 


Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 


4.3. Registration for "voicemsg" with Subtype "tel" 
Enumservice Name: "voicemsg" 
Enumservice Type: "voicemsg" 
Enumservice Subtype: "tel" 


URI Schemes: ”tel:” 
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Functional Specification: 


This Enumservice indicates that the remote resource identified can be 
addressed by the associated URI scheme in order to initiate a voice 
communication session to a voice messaging system. 

Security Considerations: See Section 3. 

Intended Usage: COMMON 


Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 


Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 


4.4. Registration for "voicemsg" with Subtype "http" 
Enumservice Name: "voicemsg" 
Enumservice Type: "voicemsg" 
Enumservice Subtype: "http" 
URI Schemes: ”http:” 
Functional Specification: 


This Enumservice indicates that the remote resource identified by the 
associated URI scheme is capable of being a source of information. 


Note that the kind of information retrieved can be manifold. Usually, 
contacting a resource by an ”http:” [11] URI provides a document. 
This document can contain references that will trigger the download 
of many different kinds of information, such as text, audio, video, 
executable code, or even voice message files. Thus, one cannot be 
more specific about the kind of information expected when contacting 
the resource. 


Security Considerations: See Section 3. 


Intended Usage: COMMON 
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Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 


Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 


4.5. Registration for "voicemsg" with Subtype "https" 
Enumservice Name: "voicemsg" 
Enumservice Type: "voicemsg" 
Enumservice Subtype: "https" 
URI Schemes: ”https:” 


Functional Specification: 


This Enumservice indicates that the remote resource identified by the 
associated URI scheme is capable of being a source of information, 
which can be contacted using TLS or the Secure Socket Layer protocol. 


Note that the kind of information retrieved can be manifold. Usually, 
contacting a resource by an ‘https:’ [12] URI provides a document. 
This document can contain references that will trigger the download 
of many different kinds of information, such as text, audio, video, 
executable code, or even voice message files. Thus, one cannot be 
more specific about the kind of information expected when contacting 
the resource. 

Security Considerations: See Section 3. 

Intended Usage: COMMON 

Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 


Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 
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5. ENUM Service Registration for videomsg 


5.1. Registration for "videomsg" with Subtype "sip" 


Enumservice Name: "videomsg" 
Enumservice Type: "videomsg" 
Enumservice Subtypes: "sip" 


URI Schemes: ”sip:” 


Functional Specification: 


This Enumservice indicates that the remote resource identified can be 
addressed by the associated URI scheme in order to initiate a video 
communication session to a video messaging system. 

Security Considerations: See Section 3. 

Intended Usage: COMMON 


Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 


Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 


5.2. Registration for "videomsg" with Subtype "sips" 
Enumservice Name: "videomsg" 
Enumservice Type: "videomsg" 
Enumservice Subtypes: "sips" 
URI Schemes: ”sips:' 
Functional Specification: 
This Enumservice indicates that the remote resource identified can be 


addressed by the associated URI scheme in order to initiate a video 
communication session to a video messaging system. 


Livingood & Troshynski Standards Track [Page 10] 


RFC 5278 VMSG Enumservice July 2008 


Security Considerations: See Section 3. 
Intended Usage: COMMON 
Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 


Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 


5.3. Registration for "videomsg" with Subtype "http" 
Enumservice Name: "videomsg" 
Enumservice Type: "videomsg" 
Enumservice Subtype: "http" 
URI Schemes: ”http:” 


Functional Specification: 


This Enumservice indicates that the remote resource identified by the 
associated URI scheme is capable of being a source of information. 


Note that the kind of information retrieved can be manifold. Usually, 
contacting a resource by an ”http:” [11] URI provides a document. 
This document can contain references that will trigger the download 
of many different kinds of information, such as text, audio, video, 
executable code, or even video message files. Thus, one cannot be 
more specific about the kind of information expected when contacting 
the resource. 


Security Considerations: See Section 3. 
Intended Usage: COMMON 
Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 
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Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 


5.4. Registration for "videomsg" with Subtype "https" 
Enumservice Name: "videomsg" 
Enumservice Type: "videomsg" 
Enumservice Subtype: "https" 
URI Schemes: ”https:” 
Functional Specification: 
This Enumservice indicates that the remote resource identified by the 
associated URI scheme is capable of being a source of information, 
which can be contacted using TLS or the Secure Socket Layer protocol. 
Note that the kind of information retrieved can be manifold. Usually, 
contacting a resource by an ‘https:’ [12] URI provides a document. 
This document can contain references that will trigger the download 
of many different kinds of information, such as text, audio, video, 
executable code, or even video message files. Thus, one cannot be 
more specific about the kind of information expected when contacting 
the resource. 
Security Considerations: See Section 3. 
Intended Usage: COMMON 


Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 


Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 
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6. ENUM Service Registration for unifmsg 
6.1. Registration for "unifmsg" with Subtype "sip" 
Enumservice Name: "unifmsg" 
Enumservice Type: "unifmsg" 
Enumservice Subtypes: "sip" 
URI Schemes: ”sip:” 
Functional Specification: 
This Enumservice indicates that the remote resource identified can be 
addressed by the associated URI scheme in order to initiate a unified 
communication session to a unified messaging system. 
Security Considerations: See Section 3. 
Intended Usage: COMMON 


Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 


Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 


6.2. Registration for "unifmsg" with Subtype "sips" 
Enumservice Name: "unifmsg" 
Enumservice Type: "unifmsg" 
Enumservice Subtypes: "sips" 
URI Schemes: ”sips:' 
Functional Specification: 
This Enumservice indicates that the remote resource identified can be 


addressed by the associated URI scheme in order to initiate a unified 
communication session to a unified messaging system. 
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Security Considerations: See Section 3. 
Intended Usage: COMMON 
Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 


Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 


6.3. Registration for "unifmsg" with Subtype "http" 
Enumservice Name: "unifmsg" 
Enumservice Type: "unifmsg" 
Enumservice Subtype: "http" 
URI Schemes: ”http:” 


Functional Specification: 


This Enumservice indicates that the remote resource identified by the 
associated URI scheme is capable of being a source of information. 


Note that the kind of information retrieved can be manifold. Usually, 
contacting a resource by an ”http:” [11] URI provides a document. 
This document can contain references that will trigger the download 
of many different kinds of information, such as text, audio, video, 
executable code, or even video message files. Thus, one cannot be 
more specific about the kind of information expected when contacting 
the resource. 


Security Considerations: See Section 3. 
Intended Usage: COMMON 
Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 


Livingood & Troshynski Standards Track [Page 14] 


RFC 5278 VMSG Enumservice July 2008 


Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 


6.4. Registration for "unifmsg" with Subtype "https" 
Enumservice Name: "unifmsg" 
Enumservice Type: "unifmsg" 
Enumservice Subtype: "https" 
URI Schemes: ”https:” 
Functional Specification: 
This Enumservice indicates that the remote resource identified by the 
associated URI scheme is capable of being a source of information, 
which can be contacted using TLS or the Secure Socket Layer protocol. 
Note that the kind of information retrieved can be manifold. Usually, 
contacting a resource by an ‘https:’ [12] URI provides a document. 
This document can contain references that will trigger the download 
of many different kinds of information, such as text, audio, video, 
executable code, or even video message files. Thus, one cannot be 
more specific about the kind of information expected when contacting 
the resource. 
Security Considerations: See Section 3. 
Intended Usage: COMMON 


Authors: 


Jason Livingood (jason_livingood@cable.comcast.com) 
Don Troshynski (dtroshynski@acmepacket .com) 


Any other information the author deems interesting: 


Implementers should review a non-exclusive list of examples below in 
Section 7. 
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7. Selected Examples for Illustrative Purposes 


The following sub-sections document several examples that 
implementers may find informative. These examples shall in no way 
limit the various forms that this Enumservice may take. 


7.1. Example Using a ’sip’ URI 


SORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 
NAPTR 10 100 "u" "E2U+voicemsg:sip" 
"I .*S!sip:12155550123@gw.example.com!". 


In this example, a calling party has attempted a session that has 
gone unanswered after a certain period of time. The calling party’s 
session is sent to the appropriate voice messaging server, a 
personalized greeting is played to the calling party, after which it 
records a voice message to the called party. 


7.2. Example Using a ’tel’ URI 


SORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 
NAPTR 10 100 "u" "E2U+voicemsg:tel" 
WTA FSTtGL:I=215-555-01231 


In this example, a calling party has attempted a session that has 
gone unanswered after a certain period of time. The calling party’s 
session is sent to the appropriate voice messaging server, a 
personalized greeting is played to the calling party, after which it 
records a voice message to the called party. 


7.3. Example Using a Backreference 


SORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 
NAPTR 10 100 "u" "E2U+voicemsg:sip" 
"!1(%,.*)S!sip:\l@example.net!". 


In this example, a backreference is used to reduce the size of the 


NAPTR record. The sip URI uses "\1", which would dynamically replace 
the expression with the TN, in this case +12155550123. 
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4. Example Using a ’sip’ URI without a Telephone Number 


SORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 
NAPTR 10 100 "u" "E2U+voicemsg:sip" 
"I*.*S!sip: johndoe@gw.example.com!". 


In this example, a calling party has attempted a session that has 
gone unanswered after a certain period of time. The calling party’s 
session is sent to the appropriate voice messaging server, a 
personalized greeting is played to the calling party, after which it 
records a voice message to the called party. The URI that this 
session is directed to does not include a telephone number, as this 
user has multiple service that are not particularly tied to telephone 
numbers whereby text, audio, video and other multimedia messages can 
be received and accessed. 


5. Example of Failover Using E2U+videomsg:sip 


SORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 
NAPTR 10 100 "u" "E2U+videomsg:sip" 
"I. *S!sip:12155550123@gwl.example.com!". 


SORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 
NAPTR 10 200 "u" "E2U+videomsg:sip" 
"I. *S!sip:12155550123@gw2.example.com!". 


In this example, the preference indicates that gwl.example.com is 
used first (100), and if this is unreachable, then the next higher 
preference (200) is used and gw2.example.com is contacted. While out 
of scope for this document, a service provider could thus mirror or 
cluster a message store and fail from the primary to secondary using 
the DNS in an active-standby mode. 


Implementation Recommendations 


-1. Call Processing When Multiple Records Are Returned 


It is likely that both E2U+sip and E2U+voicemsg, E2U+videomsg, and/or 
E2U+unifmsg Enumservice type records will be returned for a given 
query. In this case, this could result in what is essentially 
E2U+sip records for real-time communications with an end user, while, 
for example, the E2U+voicemsg records will be used for real-time 
communications with a voice messaging service, when the called party 
is not available or does not wish to be disturbed. Therefore, the 
network element that receives the results of this ENUM query will 
need to know enough information in order to select the voicemsg 
service type, rather than the sip service type. 


Livingood & Troshynski Standards Track [Page 17] 


RFC 5278 VMSG Enumservice July 2008 


8. 


10. 


In addition, it is likely that multiple E2U+voicemsg, E2U+videomsg, 
and/or E2U+unifmsg Enumservice type records will be returned for a 
given query. In this case, multiple records may include order and 
preference to allow recursion or load balancing. Order could be used 
to designate a primary and a backup voice, video, or unified voice 
and video messaging service. Preference could be used to load 
balance across multiple voice, video, and/or unified voice and video 
messaging servers by weight, for example. 


Finally, as with multiple records resulting from a typical ENUM query 
of the e164.arpa tree, it is up to the application using an ENUM 
resolver to determine which record(s) to use and which record(s) to 
ignore. Implementers should take this into consideration and build 
logic into their applications that can select appropriately from 
multiple records based on business, network, or other rules. 


NAPTR Configuration Issues 


Implementers may wish to consider using regular expressions in order 
to reduce the size of individual NAPTRs. This will have a 
significant effect on the overall size of the database involved. 


IANA Considerations 


This document registers the ”voicemsg” Enumservice type and the 
subtype "tel", "sip", "sips", "http", and "https" under the 
Enumservice registry described in the IANA considerations in RFC 
3761. Details of this registration are provided in Section 4 of this 
document. 


This document registers the ”videomsg” Enumservice type and the 
subtype "sip", "sips", "http", and "https" under the Enumservice 
registry described in the IANA considerations in RFC 3761. Details 
of this registration are provided in Section 5 of this document. 


This document registers the ’unifmsg’ Enumservice type and the 
subtype "sip", "sips", "http", and "https" under the Enumservice 
registry described in the IANA considerations in RFC 3761. Details 
of this registration are provided in Section 6 of this document. 
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